軟體開發專案的失敗，是一個在業界中常見且持續存在的問題。很多專案會被取消、大幅超出預算和時程，或未能達成其預期目標。其中最常見的原因，是使用者提出的問題不明確、被誤解或頻繁變更，導致專案最終失敗。

人月神話一書的作者Fred Brooks就說到：
“The hardest single part of building a software system is deciding precisely what to build”
“構建軟件系統的最難的部分，就是決定要構建的內容”

這句話真的道出了軟體開發專案的艱難。

在許多參考文獻中，不是只有過去是這樣，最近的調查也是顯示需求是造成軟體開發失敗的關鍵因素：

[1] Why Do Software Development Projects Fail?, Tom Sire, Nov 21, 2023
https://www.requiment.com/why-do-software-development-projects-fail/
70%的失敗原因是跟需求有關。
[2] 100+ Project Management Statistics & Facts (Updated 2025)
https://www.proprofsproject.com/blog/project-management-statistics/
47%的專案由於需求管理不善而未能達成目標。
[3] Software Survival in 2024: Understanding 2023 Project Failure Statistics and the Role of Quality Assurance, March 4, 2024
https://www.betabreakers.com/blog/software-survival-in-2024-understanding-2023-project-failure-statistics-and-the-role-of-quality-assurance/
首當其衝的是需求收集不善，佔39.03% 。

所以由這些資訊可以得知，雖然開發方法和工具不斷進步，它們只是讓事情可以做得更快，像是撰寫程式、環境部署等等，但是對於用戶腦袋裡的小劇場，開發人員依舊無法通靈，需求不知道就是不知道，不會因為工具改善而有所差別。

你會說如果需求很簡單，應該就不會發生這樣的事情吧？讓我們來看看幾個小故事。

傳話遊戲

在一個軟體開發團隊裡，有個工程師叫小明，他負責設計一個全新的功能。
有一天，團隊經理老華召集大家開會，宣布了這個功能的核心需求：「我們要開發一個可以讓使用者輕鬆分享圖片的應用程式！」小華的話簡單而直接，但這個訊息就像在一場「傳話遊戲」中被傳遞下去一樣。

圖 3-1 常見的需求困境 – 傳話遊戲

會議結束後，小明將這個訊息告訴了UX designer小強，小強又把自己的理解告訴給了測試工程師小美。

小明本來理解的是「分享圖片」，但小強在轉述時卻加上了「分享大頭貼」，而小美聽到後又理解為「分享帶有動態效果的卡通圖片」。

於是，團隊裡每個人心中的版本都略有不同，大家各自依據自己的理解開始工作。

幾週後，當產品第一次整合時，大家發現竟然出現了不同的分享模式：有的是分享簡單圖片的架構設計，有的是帶特效的動態卡通的畫面設計，甚至人是分享如何測試大頭照濾鏡的場景！
這時候，團隊才意識到問題出在哪裡：在傳遞訊息的過程中，每個人都根據自己的理解添加了新的細節，導致最終的產品與最初經理的想法大相逕庭。

傳話遊戲這種場景在軟體開發中很常見，即時需求很簡單不複雜，但是每個人對同一個訊息的理解，可能會偏離原意，最終導致產品出現許多意想不到的功能或錯誤。

你以為的明確別人不這麼想

另外，我曾經課堂中有個討論題目，詢問學員下面這個圖形中有幾個頂點。讀者看到這裡，可以先自己想想看，你自己的答案會是什麼。

圖 3-2 一個星星圖形

這個圖形看起來是典型的五角星，它有五個頂點。每個角的尖端可以算作一個頂點。因此，從數學角度來看，它應該有五個頂點。

如果觀察者將星形的每一條線段的交點都看作一個頂點，這樣的解讀就會得到10個頂點。這是因為每個外圓角的尖端和每個內部的交錯點都被認為是「頂點」。

也有學員說到 14 個頂點，因為除了上面說到的內外各5 個外，我呈現出來的投影片，畫面上是一個方形，所以再加上4個角，就是 14個。你看，這也行！

規格常常已經是解法

傳統的專案需求聚焦在「要做什麼」，卻沒有說「為什麼要做」。它們基本上是對問題的解法建議，卻沒有說明問題到底是什麼。

提出需求的客戶與商業角色通常對軟體的視角是非常有限的，這並不令人意外，因為他們自然會聚焦在業務規則與使用者介面上，而不是在技術的實作面上。因為業務人員對技術細節缺乏深入理解，他們所提出的解法，有時比實際需要的還要複雜。技術人員若理解了問題，往往能提出更簡單的解法。

例如，客戶說：「這個報表我要能下載成 Excel。」因此，客戶就希望開發團隊實作此功能，開發團隊覺得有點麻煩，目前時程來不及做出這個功能，因此和客戶討論，詢問客戶：「你需要下載做什麼呢？」客戶答：「我只是想算一下各個部門的總金額，然後貼給經理。」了解客戶真的想怎麼用後，開發團隊在原先報表上，加上「自動加總列」的功能，一下就搞定這件事情。

軟體開發失敗的根源，常常不是技術無法達成，而是「不知道要達成什麼」。即使是一個簡單的功能，如果沒有對齊彼此的理解，也可能走偏方向、浪費資源。我們不能只是滿足於「把需求寫清楚」，而是應該更進一步問：「為什麼需要這個功能？」真正的挑戰不只是寫出正確的程式，而是建立共同理解。不管在什麼時代，溝通、澄清與同理依舊是軟體專案成功與否的關鍵。

GenAI 越來越強，卻讓「需求釐清」變得更關鍵

生成式人工智慧正在加速改變軟體開發的節奏。不論是寫程式、產測試、自動補文件，甚至做 UI 原型，都能用一句話交給 AI 幫你完成。這看起來像是夢幻開發時代的到來──但現實中，很多團隊反而陷入另一種混亂：

AI 寫得又快又多，但我們還是不知道「到底要做什麼」。

你以為 GenAI 能幫你跳過討論、跳過會議、跳過需求釐清，結果卻發現：需求越不清楚，AI 產出的東西就越離譜。

GenAI 能幫哪些事？

GenAI 確實能讓開發工作更有效率，尤其在「加速資訊整理」和「降低初稿門檻」方面表現突出：

(1) 初步草稿產出
只要輸入一句話，AI 就能寫出功能說明、流程圖、甚至相關使用情境。

例：「我們需要圖片上傳與分享功能」 → GenAI 可產出：流程說明＋範例情境＋API 草稿。

(2) 整理與比對需求內容
當團隊有大量會議記錄或訪談逐字稿時，GenAI 可以快速彙整資訊、找出重複或矛盾點，有助於更早發現潛在衝突。

(3) 快速原型迭代
根據初步需求，自動生成畫面草圖，幫助用戶及早看見產品雛形，加快驗證與回饋。

(4) 補充基礎領域知識
對新手 PM 或開發者來說，AI 能解釋行業術語與基本概念，加速團隊對齊。

但 GenAI 解不了這些根本問題

如果你覺得有了 AI 就能一勞永逸，那恐怕會失望。AI 強在「生成」，卻弱在「理解」。尤其是以下這幾個面向：

(1) 隱性知識難以掌握
組織內部的習慣、未明講的默契、那些「老 PM 自然知道」的背景脈絡，是 AI 無法從字面推理出來的。

(2) 動態溝通無法取代
真正的需求確認，是透過討論、追問、舉例、不斷澄清而來的。AI 再怎麼強，也無法代替你和使用者來一場深入的 1 對 1 對話。

(3) AI 也會「一本正經地胡說八道」
它說得有道理，不代表它說得對。面對新技術或特殊情境時，GenAI 有可能用過時的知識或錯誤假設輸出錯誤結果，而你還不一定發現。

即使有 AI，需求不清還是搞不定

GenAI 是幫手，不是心靈導師。它幫你「加速做出某些東西」，但無法幫你「決定要做什麼」。如果一開始團隊沒有共識、需求沒有釐清，那麼無論用什麼工具、寫多快的測試、自動產出多少文件，最終還是做出一堆「看起來很厲害但方向錯誤」的東西。

所以，AI 越來越厲害，人與人之間的「需求對話」就越不能省。